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ABSTRACT 

We  present  a  market-like  method  for  distributed  communications  resource  management  in  the  context  of  networked  track¬ 
ing  and  surveillance  systems.  This  method  divides  communication  resources  according  to  the  expected  utility  provided 
by  information  of  particular  types.  By  formulating  the  problem  as  an  optimization  of  the  joint  utility  of  information  flow 
rates,  the  dual  of  the  problem  can  be  understood  to  provide  a  price  for  particular  routes.  Distributed  rate  control  can  be  ac¬ 
complished  using  primal-dual  iteration  in  combination  with  communication  of  these  route  prices.  We  extend  the  previous 
work  on  the  subject  in  a  few  important  ways.  First,  we  consider  utility  functions  that  are  jointly-dependent  on  flow  rates, 
to  properly  account  for  geometric  synergy  that  can  occur  in  sensor  fusion  problems.  Second,  we  do  not  require  that  the 
rate-update  algorithms  have  explicit  knowledge  of  utility  functions.  Instead,  our  update  algorithms  involve  transmitting 
marginal  utility  values.  We  present  simulation  results  to  demonstrate  the  effectiveness  of  the  technique. 
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1.  INTRODUCTION 

Tracking  and  surveillance  networks  frequently  suffer  from  significant  communication  resource  constraints.5  In  the  face 
of  limited  bandwidth  and  restrictions  introduced  by  network  topology,  questions  arise  as  to  what  information  should  be 
transmitted.  This  resource  management  problem  is  made  more  interesting  by  the  existence  of  geometrically  synergistic 
combinations  of  sensors  that  can  best  observe  a  target — that  is,  produce  a  given  quality  state  estimate  with  minimal  com¬ 
munication.  For  example,  in  video  applications,  the  range  to  a  target  generally  cannot  be  determined  using  a  single  observer 
(absent  ground  constraints  or  other  information).  A  similar  situation  often  exists  with  radar  systems,  in  which  case  very 
accurate  range  information  is  available,  but  angular  errors  can  be  quite  large.  Networked  tracking  systems  with  sensors 
that  lack  quality  information  in  some  dimension  benefit  greatly  from  multiple  observers,  gaining  the  geometric  diversity 
needed  to  form  good  quality  tracks. 

The  problem  then  becomes  one  of  determining  the  group  of  sensors  and  their  relative  contributions  that  provides  the 
best  information  on  a  target.  To  this  end,  one  can  define  a  joint  “utility”  function  that  provides  a  measure  of  effectiveness 
as  a  function  of  the  rate  at  which  information  of  different  types  is  received.5  For  example,  an  “information  type”  might 
be  defined  to  be  observations  corresponding  to  a  particular  sensor-target  pair,  or  perhaps  a  search  for  new  targets  by  a 
particular  sensor.  This  joint  utility  function  and  its  derivatives  are  evaluated  at  certain  points  in  the  network  at  which  the 
flows  are  collected,  such  as  command  centers. 

The  resulting  problem  has  a  simple  form:  maximize  the  (generally  nonlinear)  joint  utility  subject  to  bandwidth  and  flow 
constraints.  Global  planning  methods  for  solving  this  problem  can  suffer  when  used  in  rapidly-changing  environments — 
objective  functions  or  constraints  may  change  too  quickly  for  a  centralized  solver  to  adapt  and  communicate  a  new  strategy. 
A  distributed  solution  makes  sense:  as  local  conditions  or  commander  needs  change,  communications  can  be  adapted  so 
as  to  best  utilize  the  available  bandwidth. 

In  this  work  we  present  such  a  solution,  which  builds  on  an  approach  that  has  been  widely  applied  in  the 
communication-networks  literature.  The  dual  of  the  optimization  problem  (namely,  joint  utility  maximization  subject 
to  capacity  constraints)  yields  to  an  economic  interpretation  wherein  each  communication  link  has  a  price  given  by  the 
dual  variable  in  the  Lagrangian  associated  with  that  link’s  capacity  constraint.  The  route  taken  by  a  particular  type  of 
information,  then,  has  a  price  equal  to  the  sum  of  the  prices  of  the  links  along  the  route.  Communication  of  these  route 
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and  link  prices,  along  with  the  marginal  utility  of  an  information  type,  permits  a  naturally  distributed  optimization  strategy 
in  which  sensors  locally  modify  transmission  rates.  By  including  joint  utility  functions,  we  can  account  for  the  kind  of 
geometric  synergy  mentioned  earlier. 

This  paper  is  organized  as  follows:  Section  2  discusses  the  utility  and  pricing  structure.  Section  3  covers  the  distributed 
rate  control  algorithm,  and  Section  4  shows  some  simple  experimental  verification  of  the  algorithm. 

2.  UTILITY  AND  PRICING  FRAMEWORK 

2.1.  Problem  Formulation 

The  problem  formulation  here  builds  on  the  work  of  Brewington  et  al.3  However,  we  deviate  here  in  one  aspect  of  the  for¬ 
mulation:  we  assume  that  associated  with  each  end-to-end  communication  is  a  predefined  route  (path)  through  the  network 
(in  Section  2.3  we  discuss  the  case  of  multiple  routes).  This  assumption  is  common  in  the  literature  on  communication 
networks  (see,  e.g..  Refs.  7-11, 13).  In  particular,  we  adopt  a  framework  based  on  the  work  of  Low  and  Lapsley,9  which 
builds  on  a  classical  idea  from  economics. 

In  this  section,  we  first  provide  a  detailed  formulation  of  the  rate  optimization  problem.  We  then  discuss  a  distributed 
solution  approach  to  the  rate  optimization  problem,  based  on  duality  theory. 

2.1.1.  Network  and  data  types 

To  begin,  consider  a  communication  network  consisting  of  a  set  of  nodes  and  a  set  of  L  links  connecting  these  nodes.  Index 
the  links  by  l  =  1 .....  L.  Associated  with  each  link  l  is  a  fixed  capacity  value  c/. 

We  have  N  data  types  to  be  communicated  over  the  network.  Each  data  type  has  a  source  node  and  a  destination  node. 
Index  the  data  types  by  *  =  1,2 , ,N.  For  each  data  type,  we  refer  to  the  data  communicated  through  the  network  as  its 
flow. 

Example  1.  (Motivated  by  the  setup  in  Brewington  et  al.3)  Consider  a  set  of  sensors  E  and  a  set  of  targets  T  (capital 
“tau”).  Each  sensor  is  located  at  a  node,  and  has  measurements  from  one  or  more  of  these  targets.  For  each  sensor,  these 
target  measurements  are  to  be  sent  from  the  sensor  node  to  a  commander  (located  at  some  other  node).  In  this  case,  each 
sensor-target  pair  (tr,  r),  a  £  E,  r  £  T,  is  a  data  type.  □ 

Associated  with  each  data  type  i  =  1, . . . ,  N  is  a  prespecified  route,  which  is  an  acyclic  list  of  consecutively  conjoined 
links  through  the  network  starting  at  the  source  of  data  type  i  and  ending  at  its  destination  (the  route  is  fixed  but  otherwise 
arbitrary).  Let  R(i)  represent  the  set  of  links  on  the  route  of  data  type  i.  For  data  type  i,  the  quantity  of  flow  being 
communicated  is  called  the  flow  rate  (a  nonnegative  quantity),  denoted  /).  Associated  with  each  flow  rate  are  prespecified 
maximum  and  minimum  constraints:  m*  <  fi  <  Mj. 

Each  link  in  the  network  may  carry  flows  from  multiple  data  types.  For  each  link  l  =  1, . . . ,  L,  let  F(l)  be  the  set 
of  data  types  communicating  through  it.  The  sum  of  the  flow  rates  on  each  link  should  not  exceed  the  link  capacity: 

J2i£F(l)  fi  <  =  1)  ■  •  ■  )  L. 

2.1.2.  Utility  optimization 

Our  task  is  to  set  the  values  of  the  flow  rates  /i, . . . ,  /jv  (subject  to  the  link-capacity  constraints  mentioned  above).  The 
setting  of  these  values  is  based  on  maximizing  a  joint  utility  function  U  (/i, . . . ,  /at).  This  notion  of  a  joint  utility  function 
is  more  general  than  the  utility  formulation  in  Brewington  et  al.3  and  in  Low  and  Lapsley.9 

For  convenience,  let  /  =  [/i, . . . ,  /,y]7  denote  the  vector  of  flow  rates,  and  (with  some  harmless  abuse  of  notation)  let 
U (/)  be  the  (joint)  utility  value  associated  with  /.  Let  V  =  {/  :  to*  <  /,  <  Mj,  i  =  1, . . . ,  N}  denote  the  set  of  rate 
vectors  satisfying  the  max  and  min  constraints  on  their  respective  components.  We  call  any  such  vector  feasible. 

To  summarize,  our  optimization  problem  is  to  find  a  feasible  rate  vector  maximizing  the  joint  utility  function  subject 
to  link-capacity  constraints: 


maximize  U(f) 
feT>  v 

subject  to  <  ci,  l  =  1, . . . ,  L. 

i£F(l) 


(1) 


Example  2.  Consider  the  sensor-target  data-type  scenario  from  Example  1.  Suppose  that  the  utility  functions  are  jointly 
dependent  only  through  the  sensors  that  provide  the  data  for  that  target,  but  are  not  jointly  dependent  across  targets.  To 
elaborate,  for  each  target  r  £  T,  let  UT  be  the  utility  function  for  target  r,  and  fT  the  vector  of  flows  associated  with 
t  (the  components  of  fT  correspond  to  all  sensor-target  pairs  (er,  r),  a  £  E).  The  utility  function  UT  depends  only  on 
fT,  and  not  on  any  other  flow  rates.  Then,  following  Brewington  et  al.,3  the  overall  joint  utility  function  is  given  by 
U(f)=EreTUr(fT). 

A  further  special  case  is  where  UT  depends  on  fT  only  through  the  aggregate  flow  rate  for  target  r;  i.e.,  there  is  a 
function  U  such  that  UT ( f  T )  =  U  d 

Example  3.  Consider  again  the  sensor-target  data-type  example  from  before.  Suppose  that  we  have  number  of  com¬ 
manders,  indexed  by  n  £  K.  Commander  k  needs  to  receive  only  those  flows  that  are  associated  with  a  certain  subset  of 
targets,  TK.  Let  f  K  denote  the  vector  of  flows  associated  with  TK  (the  components  of  f  K  correspond  to  all  sensor-target 
pairs  (<r,  r)  such  that  r  £  TK).  Note  that  even  for  two  distinct  commanders  and  K2,  the  vectors  f  and  /  may  share 
one  or  more  components. 

Each  commander  has  a  utility  function  UK{f  K)  (which  depends  only  on  f  K  and  not  on  the  flows  of  other  sensor-target 
pairs).  Then,  the  overall  joint  utility  function  is  U  (/)  =  UK(fK). 

The  utility  functions  UK  may  encode  information  about  the  relative  “values”  (or  “ranks”)  of  different  commanders.  For 
example,  it  may  be  the  case  that 

max  UKl  (/ Kl )  >  maxC/K2(/K2), 

J  Kl  T  K 2 

reflecting  a  higher  importance  in  maximizing  the  utility  of  commander  k-\  .  □ 

2.2.  Types  of  Joint  Utility  Functions 

In  our  framework,  the  utility  function  U  depends  jointly  on  the  flow  rates  / 1, . . . ,  /,v .  It  is  useful  to  categorize  different 
ways  in  which  the  utility  depends  jointly  on  these  flow  rates.  In  the  simplest  case,  the  joint  utility  function  is  the  sum  of 
utility  functions  of  individual  flows: 


U(/i,  •  •  •  ,/at)  =  Ui(fi)  + - f  UN(fN). 

We  refer  to  such  flows  as  independent.  This  is  the  usual  case  considered  in  the  data-networking  literature  (e.g.,  Refs.  7- 
1 1, 13).  It  is  easy  to  show  that  if  each  individual  Ui,i=  1 .....  A,  is  concave,  then  U  is  concave. 

A  second  category  of  joint  dependence  is  characterized  by  the  following: 

U(fi,...,fN)  =  Uc(min(/i, . . . ,  fN)) 

for  some  Uc  :  R  — >  R.  We  refer  to  such  flows  as  complementary,  following  the  classical  terminology  in  the  economics 
literature  (e.g..  Ref.  12).  The  basic  idea  here  is  that  the  utility  value  depends  on  a  “combination”  of  flows,  so  that  if  we 
only  have  a  certain  amount  of  data  from  one  flow,  no  additional  utility  is  gained  by  having  more  data  from  other  flows.  It 
is  easy  to  show  that  if  Uc  is  concave,  then  so  is  U. 

The  above  form  of  utility  function  U  reflects  an  extreme  form  of  complementary  flows,  often  called  “perfect”  comple¬ 
ments  (analogous  to  nuts  and  bolts).  Less  extreme  forms  of  complementarity  (more  like  bread  and  butter)  involve  some 
gain  in  utility  from  data  of  flows  greater  than  the  least  flow,  but  not  as  much  as  would  be  obtained  in  the  independent  case. 
Complementary  flows  are  particularly  relevant  in  tracking/surveillance  applications.  For  example,  tracking  performance 
typically  depends  on  a  combination  of  data  from  multiple  sensors,  and  the  lack  of  data  from  one  sensor  cannot  be  signifi¬ 
cantly  ameliorated  by  more  data  from  other  sensors.  This  is  common  in  tracking  when  information  on  some  dimension  is 
poor  or  even  totally  unavailable  (as  can  be  true  in  radar  or  visible-band  surveillance). 

A  third  category  of  joint  dependence  is  given  by  the  following: 

U(fl,  ■  ■  ■  ,  /n)  =  Ug(fl  +  ■  ■  ■  +  /n) 

for  some  Us  :  K.  — ►  R.  In  this  case,  the  flows  are  called  substitute  flows — the  data  from  one  flow  can  be  substituted  by  data 
from  other  flows  with  no  change  in  utility.  The  above  form  of  utility  function  involves  “perfect”  substitution.  Less  extreme 


Figure  1.  Level  sets  of  utility  functions  with  two  fbws:  (a)  complementary  (concave);  (b)  independent  (concave);  (c)  substitute  (con¬ 
cave);  (d)  duplicate  (not  concave). 


forms  of  substitute  flows  involve  some  change  in  utility  if  we  substitute  one  flow  with  another.  It  is  easy  to  show  that  if  Us 
is  concave,  then  so  is  U. 

In  general,  utility  functions  could  involve  combinations  of  flow  types.  For  example:  =  Ui(fi)  + 

^2,3  (/2 1  fd.)  where  /2  and  / 3  are  complementary  flows,  and  /1  is  independent  of  the  pair  (/2,  ff).  This  example  is  consid¬ 
ered  in  Section  4. 

One  other  category  of  flows  is  worth  mentioning:  duplicate  flows.  In  the  “perfect”  duplicate  case,  we  have 


U{fi,...,fN)  =  f/d(max(/i,. . . ,  fN)) 

for  some  U4  :  II  -»  1.  In  this  case,  information  from  one  flow  duplicates  information  from  another — once  we  have  data 
from  one  flow,  no  additional  utility  is  gained  from  other  lesser  flows.  This  would  be  the  case  if,  for  example,  we  send  the 
same  sensor  data  over  multiple  routes,  treating  each  route  as  a  distinct  flow.  We  typically  do  not  consider  the  duplicate-flow 
case  because  the  utility  function  U  in  this  case  is  not  concave,  even  if  Ud  is  concave.  Concavity  is  important  in  solving  the 
utility  maximization  problem;  see  Section  3.1. 

Figure  1  illustrates  the  types  joint  utility  functions  discussed  above. 

2.3.  Multiple  Routes  per  Flow 

Our  formulation  thus  far  of  the  rate-control  problem  assumes  a  single  route  for  each  data  type.  This  assumption  is  common 
in  the  current  literature  on  data-communication  networks.  However,  it  is  often  of  interest  to  consider  the  case  where  each 
data  type  has  multiple  routes  for  communicating  its  data.  It  turns  out  that  by  having  joint  utility  functions,  the  single -route 
assumption  holds  without  loss  of  generality.  In  particular,  we  show  here  how  to  account  for  the  case  where  a  single  data 
type  has  multiple  routes. 

Consider  a  particular  data  type  i  and  a  set  of  multiple  routes,  indexed  by  k  =  1 , ,R,  associated  with  this  data  type. 
Suppose  that  the  flow  for  data  type  i  is  split  across  these  routes,  so  that  the  aggregate  flow  over  these  routes  constitutes  the 
flow  for  the  data  type,  denoted  /)  as  usual. 

For  each  k ,  define  a  virtual  data  type,  indexed  by  the  pair  i,  /.:,  and  associate  with  this  virtual  data  type  the  route  k.  Let 
f  itk  be  the  flow  rate  for  virtual  data  type  i,  k.  Then,  the  flow  rate  for  data  type  i  is  given  by  /,  =  f-11  +  •  •  •  +  fiR.  We  can 
now  treat  each  virtual  data  type  as  an  individual  data  type  in  the  setting  of  our  rate-control  problem,  where  replace  data 
type  i  by  the  virtual  data  types.  Specifically,  the  utility  function  U  (which  has  /,  as  one  of  its  arguments)  is  replaced  by  the 
following: 

Uv{-  ■  ■  ,  /i,  1,  ■  •  •  ,  fitR,  ■■■)  =  [/(■■■  ,  fitl  +  •  •  •  +  fitR,  ■  ■  ■). 

In  other  words,  the  constituent  (virtual)  flows  for  data  type  i  are  perfect  substitute  flows  with  respect  to  the  joint  utility 
function  involving  the  virtual  data  types.  Our  previous  framework  (assuming  a  single  route  per  flow)  now  applies. 

2.4.  Utility  on  Object  Types 

Suppose  we  have  a  set  of  object  types  and  a  utility  function  over  the  quantities  of  objects.  Specifically,  if  j  =  1, . . . ,  M  is 
the  index  for  object  types,  and  g  1, . . . ,  (j\j  are  their  (scalar)  “quantities,”  then  V(g  1, . . . ,  5m)  is  the  utility  received.  Our 
goal  is  to  maximize  this  utility  value.  But  we  do  not  have  direct  control  over  g  1,  .  . .  ,5m-  What  we  can  control  are  the 
data-type  flow  rates  /1, . . . ,  /  y,  and  these  flow  rates  affect  the  object-type  quantities.  In  a  surveillance  application,  this 


might  manifest  itself  as  obtaining  benefit  from  observations  of  a  certain  type  of  target,  where  one  can  only  control  the  rate 
at  which  observations  of  all  targets  are  sent.  Similar  arguments  can  be  made  to  handle  observation-to-track  association 
ambiguity;  there  may  be  utility  only  for  correct  associations. 

To  capture  how  the  flow  rates  affect  the  object  quantities,  we  use  the  following  model.  For  each  data  type,  we  have  a 
probability  distribution  over  object  types.  (Call  this  the  data  association  law.)  This  allows  us  to  construct  a  utility  function 
over  the  flow  rates,  U(fi, . . . ,  /at),  such  that  maximizing  this  utility  function  maximizes  the  mean  utility  value  of  object 
quantities.  The  framework  we  have  developed  above  is  therefore  also  useful  in  this  context. 

To  be  precise,  let  f  and  g  be  vectors  representing  data-type  flow  rates  and  object-type  quantities,  respectively.  Then, 
given  /,  the  data  association  law  is  specified  by  a  conditional  probability  distribution  P(-\f)  over  possible  values  of  object- 
type  quantities.  Given  the  utility  function  V  over  object-type  quantities,  define  a  utility  function  U  over  data-type  flow 
rates  by 

U(f)  =  E[V(Q)\f]  =  J2  V(g)P(g\f).  (2) 

9 

Then,  maximizing  U (/)  (under  the  framework  introduced  earlier)  maximizes  the  conditional  mean  of  V(g)  given  /  (with 
respect  to  the  data  association  law). 

Example  4.  Consider  once  again  the  scenario  with  sensors  taking  measurements  of  targets.  Suppose  that  each  sensor  has 
a  number  of  measurements,  but  we  cannot  be  certain  which  measurement  corresponds  to  which  target.  Instead,  for  each 
measurement,  we  have  a  probability  distribution  over  targets — this  distribution  specifies,  for  each  target,  the  probability 
that  each  given  measurement  is  associated  with  that  target. 

Suppose  object  types  represent  targets,  and  data  types  represent  sensor-measurement  pairs.  So  /,  represents  the  flow 
rate  for  sensor-measurement  pair  i,  and  gT  represents  the  measurement  rate  for  target  r.  What  a  commander  specifies  is 
(as  before)  a  joint  utility  function  V  over  rates  of  measurements  for  targets  V (g). 

As  a  special  case,  the  commander  may  specify,  for  each  target  r  £  T,  the  utility  function  VT(gT)  (which  depends 
only  on  the  measurement  rate  for  target  gT.  The  target-specific  utility  functions  give  rise  to  an  overall  utility  function 
V (g)  =  X)tgt  Vr(gr)-  We  are  also  given  the  data  association  law  P(g\f).  We  can  now  define  U(f)  via  (2)  and  apply  the 
framework  described  above.  □ 


3.  DISTRIBUTED  RATE-CONTROL  ALGORITHM 
3.1.  Primal-Dual  Formulation  of  Rate  Control  Problem 

Our  next  goal  is  to  develop  a  distributed  scheme  to  solve  the  basic  rate-control  problem  (1).  We  follow  the  duality  approach 
of  Low  and  Lapsley.9  This  approach  has  proven  to  be  successful  in  dealing  with  distributed  congestion  control  problems 
in  data  networks,  including  the  Internet,  with  significant  ongoing  work  (see,  e.g..  Refs.  9, 10, 13,  and  also  Refs.  7, 8, 1 1  for 
some  earlier  work  along  related  lines).  For  an  excellent  treatment  of  duality  theory  for  nonlinear  programming  problems, 
see  Boyd  and  Vandenberghe.1 

The  duality  approach  goes  roughly  as  follows.  For  the  given  problem  (1),  we  introduce  another  related  problem  called 
its  “dual,”  with  the  property  that  solving  the  dual  somehow  aids  in  solving  the  primal.  In  fact,  the  dual  and  primal  taken 
together  yield  an  algorithm  that  has  a  natural  distributed  implementation. 

To  begin,  define  the  Lagrangian  function 

L 

£(f,p)  =  u(f)  +  Y,pl 

i=i 

where  p  =  [pi, . . .  ,pl]t  is  a  vector  of  dual  variables  (often  also  called  shadow  prices,  or  simply  prices).  In  the  context 
of  our  problem,  we  will  call  these  variables  the  link  prices. 

For  convenience,  the  Lagrangian  can  be  rewritten  as 


£(/.p)  =  tf(/)  +  X> 


E 

ieF(l) 


N  L 

U(f)  -E/^  +  E^  =  -rTf  +  cTp, 
i=  1  1=1 


Cl  ~ 


where  r,  =  Pi  represents  the  route  price  for  the  data  type  i,  r  =  [n , . . . ,  rjv]T  is  the  vector  of  route  prices,  and 

c  =  [ci , . . . ,  cl]t  is  the  vector  of  link  capacities. 

Next,  we  construct  the  dual  objective  function: 


N 


Dip)  =  max£(/,p)  =  max  (  U{f)  -  Y  f, 


=  max  (U{f)  -  rq 


f) 


T 

C  p. 


Let  us  call  (1)  the  primal  problem.  The  corresponding  dual  problem  is  given  by 


minimize  D(jp ),  (3) 

p>  o 

where  the  notation  p  >  0  means  that  every  component  of  p  is  nonnegative. 

We  make  two  additional  assumptions  (and  continue  to  hold  them  for  the  remainder  of  the  paper): 


Al.  The  function  U  is  concave. 

A2.  There  exists  /  such  that  m,  <  f  <  Mt,  i  =  1, . . . , N,  and  YlieF(i)  /*  —  ci>  l  =  1, .  ■  ■  ,L. 

Assumption  Al  is  relatively  standard  in  the  theory  of  utility  functions.  Assumption  A2,  called  Slater’s  condition,  is  natural 
in  our  context,  and  should  be  expected  to  hold  in  practice  (it  requires  only  that  there  is  an  interior  point  of  V  satisfying 
link-capacity  constraints).  Under  these  two  assumptions,  a  condition  called  strong  duality  holds  (see  Ref.  1).  Strong  duality 
has  the  following  consequences.  If  p  is  a  solution  to  the  dual  problem,  then  arg  max  fGT>  C(  f .  p)  is  a  solution  to  the  primal 
problem  (i.e.,  is  a  vector  of  optimal  rates).  But 

argma  x£(/,p)  =  arg  max  ( U(f )  —  rT  f)  . 

/ex>  /er> 

Thus,  once  we  have  an  optimal  price  vector  p,  we  can  find  the  optimal  flow  rates  by  maximizing  U (/)  —  rT  f.  Conversely, 
if  /  is  an  optimal  rate  vector,  then  (again  under  strong  duality)  arg  minp>0  C(  f .  p)  is  a  solution  to  the  dual  problem.  This 
primal-dual  optimization  result  forms  the  basis  for  a  distributed  rate-control  scheme. 

3.2.  Distributed  Rate  Control:  Primal-Dual  Iterations 

We  now  describe  a  “primal-dual  iteration”  method  to  find  the  optimal  prices  and  rates,  following  Low  and  Lapsley. 9  In 
other  words,  we  iteratively  update  rates  and  prices,  one  at  a  time:  for  the  primal  we  maximize  the  Lagrangian  with  respect 
to  /,  and  for  the  dual  we  minimize  the  Lagrangian  with  respect  to  p.  To  be  more  precise,  let  t,  be  the  iteration  index.  We 
construct  a  scheme  to  update  ( f{t),p{t ))  to  (f{t  +  1  ),p{t  +  1)),  in  two  steps,  as  follows.  First,  we  update  only  the  dual 
variable  p{t),  keeping  /(f)  fixed,  to  obtain  ( f{t),p(t  +  1)).  Then,  we  update  the  primal  variable  /(f),  keeping  p(t  +  1) 
fixed,  to  obtain  (/(f  +  1),  p(t  +  1)).  These  steps  are  described  next. 

For  the  dual,  we  use  a  “projected  gradient  algorithm”  (see,  e.g..  Ref.  4)  to  compute  prices: 

p(t  +  1)  =  [pit)  -  7Vp£(/(f),p(f))]+, 

where  Vp£  is  the  gradient  of  C  with  respect  to  its  price  argument,  7  >  0  is  a  (sufficiently  small)  step  size,  and 
[•]_!_  =  max(-,0).  Let  Vp£(/(f),p(f))  represent  the  gradient  of  C  with  respect  to  its  second  argument,  p,  evaluated 
at  if  it),  pit))).  Now,  the  Zth  component  of  Vp£(/(f),p(f))  (partial  derivative  with  respect  to  pi)  is  given  by 

dP,£if(t),p(t))  =  ci  -  fiit)=ci-ai(t) 

ieF(l) 

where  ai  =  fi  is  the  aggregate  link  rate  for  link  l.  Hence,  the  projected  gradient  algorithm  can  be  written 

component-wise  (i.e.,  in  a  link-by-link  fashion)  as 


Plit  +  1)  =  [piit)  +  7 Mf)  -  c;)]+,  l  = 


(4) 


Notice  that  this  algorithm  relies  only  on  information  that  is  locally  available  at  link  l,  and  hence  has  a  naturally  distributed 
implementation.  Note  also  that  in  the  course  of  the  algorithm  we  allow  the  aggregate  link  rate  ai(t)  to  exceed  the  link 
capacity  ci,  so  that  ai(t)  —  ci  may  be  positive.  In  this  case,  the  algorithm  increases  the  price  at  iteration  t.  The  goal  is  that 
the  algorithm  converges  to  a  point  where  the  aggregate  link  rates  satisfy  the  link-capacity  constraints. 

Having  updated  the  dual  variable  p(t)  to  p(t  + 1),  we  now  fix  p(t  +  1)  and  update  the  primal  variable  /(£)  to  /(£  +  1). 
At  iteration  t,  we  have 

f(t  +  1)  =  argmax  (U(f)  -  r(t+l)Tf)  , 
fev 

where  we  recall  that  r(t  +  1)  =  [r\(t  +  1), . . . ,  rjv(£  +  1)]T  is  the  vector  of  route  prices  at  iteration  £,  and  ri(t  +  1)  = 
Sieit(i)  Pitt  +  1)  *s  t^le  route  price  for  data  type  i  (after  the  dual  update).  Assume  that  U  is  differentiable.  Let  /(£  +  1) 
satisfy  VC/(/(£  +  1))  =  r(t  +  1).  Then,  for  the  ?th  component  of  /(£  +  1),  set  /*(£  +  1)  =  [/,;(£  +  where  the 

notation  [-]^  is  defined  by 

{TOj  if  /  <  TO; 

/  if  mi<f<Mi 

Mi  if  f  >  TOj, 

which  represents  the  projection  operator  into  the  set  of  feasible  rates. 

We  can  implement  the  computation  of  f(t  +  1)  in  a  distributed  way.  To  describe  such  an  implementation,  suppose  we 
have  a  number  of  local  updating  agents.  We  associate  with  each  agent  one  or  more  data  types — each  agent  performs  the 
updates  of  the  rate  variables  associated  with  it. 

Example  5.  Suppose  data  types  represent  sensor-target  pairs,  and  agents  correspond  to  sensors.  Then,  each  sensor  a 
updates  the  rates  for  all  sensor-target  pairs  associated  with  it:  faT,  t  £  T.  □ 

For  simplicity  of  notation,  consider  the  agent  associated  with  data  types  1 ,m.  This  agent  performs  the  following 
update:  compute  /i(£  +  1), . . . ,  fm(t  +  1)  by  solving  the  set  of  equations 


dfiU(fl(t  +  1),  .  .  .  ,  fm(t  +  1),  /m+l(f),  •  •  •  ,fN{t))  =Vi(t+l),  i=  (5) 

and  then  setting  fi(t  +  1)  =  [ft(t  +  i  =  1 , ,m.  This  method  of  computing  /) (£  +  1)  is  akin  to  “coordinate 

descent”  (see,  e.g..  Ref.  2),  although  there  may  be  multiple  “coordinates”  being  updated  simultaneously  here.  Notice 
that  some  communication  between  updating  agents  is  necessary:  to  update  its  own  component(s),  every  agent  uses  other 
components  from  the  vector  /(f).  To  be  more  precise,  updating  the  components  1, . . .  ,m  involves  knowledge  of  the 
marginal  utility  functions 

dfiU(fi,...,fm,fm+i(t)...,fN(t)),  i  =  l,...,m 

(as  functions  of  /i , . . . ,  fm).  Information  necessary  to  compute  this  marginal  utility  function  needs  to  be  communicated  to 
the  agent  updating  the  rates  for  data  types  1 ,m.  We  address  this  issue  further  in  the  next  section. 

3.3.  Distributed  Rate  Control:  Some  Refinements 

The  rate-control  method  in  the  last  section  follows  Low  and  Lapsley,9  who  assume  that  the  utility  function  involves 
independent  flows,  and  that  the  each  individual  flow  source  acts  as  the  local  updating  agent  for  the  flow.  In  the  case  of 
independent  flows,  the  update  equation  (5)  can  be  implemented  at  individual  sources  without  any  communication  of  rates 
between  sources.  This  is  not  the  case  in  our  general  formulation — if  the  flows  are  not  independent,  then  (5)  involves 
knowledge  of  potentially  all  N  rate  values.  Because  these  values  are  usually  not  available  locally  at  the  updating  agent, 
they  have  to  be  communicated.  This  communication  may  incur  a  prohibitive  burden  on  network  resources.  Moreover,  in 
many  situations  of  interest  the  utility  functions  are  unknown  to  the  updating  agents.  For  example,  the  utility  functions  might 
represent  target  tracking  performance  metrics,  such  as  the  trace  of  the  error  covariance.3  Utility  is  likely  best  connected 
to  a  mission  at  some  downstream  recipient  (say,  a  centralized  tracker),  while  updating  agents  are  typically  implemented 
at  sensor  locations.  Furthermore,  because  of  the  mobility  of  the  target  and  the  sensor  platform,  utility  functions  will  vary 
with  time. 

To  overcome  the  problem  of  requiring  the  updating  agents  to  know  the  utility  functions,  and  having  to  communicate 
rate  values  to  implement  (5),  we  introduce  some  modifications  to  the  rate-update  mechanism.  First,  we  note  that  instead  of 


updating  the  rate  vector  using  (5),  we  could  use  a  projected  gradient  algorithm  similar  to  (4).  Specifically,  the  local  update 
agent  for  flow  i  computes  /,  (<  +  1)  using 

fi(t  +  1)  =  +  a(dfiU(f(t))  -  n{t  +  1))C‘.  (6) 

This  form  of  rate  updating,  like  (4),  is  “incremental”  in  nature.  The  step  size  a  >  0  controls  the  size  of  the  increment  at 
each  iteration.  Note  that  implementation  of  (6)  involves  knowing  only  the  value  of  the  marginal  utility  dfiU(f(t));  we 
do  not  need  explicit  knowledge  of  the  rate  vector  f(t)  or  of  the  marginal  utility  function,  in  contrast  to  (5).  The  marginal 
utility  values  can  be  obtained  (calculated)  by  the  consumer  of  the  data  (e.g.,  a  commander),  who  already  receives  the  flows 
and  does  not  need  flow  rates  explicitly  communicated  to  him.  These  marginal  utility  values  still  have  to  be  communicated 
to  the  rate-updating  agent,  but  this  communication  burden  is  potentially  a  small  fraction  of  the  burden  involved  in  (5). 

In  practice,  the  implementation  of  the  update  mechanisms  (4)  and  (6)  are  asynchronous  and  involves  delayed  versions 
of  rates  and  prices.  Specifically,  in  the  right-hand  side  of  (4),  the  aggregate  link  rate  that  is  used  is  the  actual  link  rate  at  the 
time  t  of  the  update,  which  typically  involves  delayed  versions  of  flow  rates  (computed  at  times  prior  to  /  ).  Similarly,  in  the 
right-hand  side  of  (6),  the  route  price  involves  link  prices  available  to  the  updating  agent  at  time  f,  typically  computed  prior 
to  time  t,  and  the  marginal  utility  value  involves  flow  rates  updated  prior  to  time  t.  Such  delays  typically  do  no  violence 
to  the  asymptotic  properties  of  the  algorithm.2  However,  the  transient  behavior  may  be  affected  significantly  (e.g.,  large 
oscillations). 

To  improve  the  transient  behavior  of  the  price  and  rate  update  mechanisms,  we  introduce  “second-order”  terms  to  the 
update  equations.  Specifically,  for  the  price-update  algorithm  for  link  /,  we  use 

Si  (t)  =  (flow  on  link  l  at  time  t )  —  q 
pi{t  +  1)  =  \pi{t)  +  7i Si(t)  +  72 (Si(t)  -  Si(t  -  1))]+, 

and  for  the  rate-update  algorithm  for  flow  i  we  use 

Pi(t)  =  (marginal  utility  at  t )  —  (route  price  at  f) 

fi(t  +  1)  =  +  «i fait)  +  a2(/?»(f)  -  0i(t  - 

These  update  algorithms  are  akin  to  “PI  controllers,”  common  in  industrial  control  systems.6  Note  that  there  are  now  two 
step-size  parameters  in  each  algorithm,  one  for  the  first-order  term  (as  before)  and  another  for  the  second-order  term. 
Appropriate  setting  of  these  parameter  values  improves  the  transient  behavior  significantly. 

3.4.  KKT  Optimality  Condition 

Assuming  A1  and  A2  as  before,  the  Karush-Kuhn-Tucker  (KKT)  condition  provides  a  necessary  and  sufficient  condition 
for  optimality.  To  elaborate,  suppose  (/,  p)  is  a  given  feasible  pair  of  flow-rate  and  link-price  vectors  (/  7  'D  and  p  >  0). 
Then,  this  pair  is  optimal  in  their  respective  primal/dual  problems  if  and  only  if  the  following  hold: 
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The  above  set  of  equations  and  inequalities  is  called  the  Karush-Kuhn-Tucker  (KKT)  condition.4  For  convenience,  we 
rewrite  all  inequalities  as  equations  using  the  equivalence  x  >  0  <t4>  [a;]_  =  min  (a:,  0)  =  0: 

for  i  =  1, ...  ,N  :  [dfiU(f)  -  n\+ =  0  if  /*  = 

for  i  =  1, . . . ,  N  :  dftU(f  )  -  r,  =  0  if  m,  <  ft  <  Mi 
for  i  =  1, . . . ,  N  :  [dfiU(f)  -  r»]_  =  0  if  fi  =  Mi 
for  l  =  1, . . . ,  L  :  pi(ci-ai)  =  0 
for  l  =  ,L  :  [ci-ai}-  =  0. 
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Figure  2.  (a)  Seven-link  network  and  routes  for  the  three  fbws.  (b)  Queues  at  input  to  link  7. 


Write  the  entire  left-hand  side  of  the  above  equation  as  a  vector  K(f,p),  so  that  the  KKT  condition  may  be  rewritten  as 
K(f,  p)  =  0.  Define  the  KKT  norm  for  a  pair  (f,p)  as  rj(f,p)  =  ||.K’(/,p)||.  Then,  a  necessary  and  sufficient  condition 
for  optimality  of  the  pair  (f,p)  is  rj(f,  p)  =  0.  We  will  use  the  KKT  norm  as  a  measure  of  “distance  from  optimality.”  In 
particular,  our  update  algorithms  converge  to  optimality  if  and  only  if  T](f(t),p(t))  — ■>  0  as  t  — *  oo. 

4.  EMPIRICAL  EVALUATION 

The  main  goal  of  this  section  is  to  illustrate  the  operation  and  convergence  of  the  algorithm.  To  this  end,  we  consider  a 
fixed  network  and  three  different  scenarios  on  this  network.  These  three  scenarios  cover  the  three  types  of  joint  dependence 
of  flows  in  the  utility  function:  independent,  substitute,  and  complementary. 

The  network  we  consider  is  illustrated  in  Figure  2(a).  There  are  L  =  7  links.  (The  label  on  each  link  is  its  index,  needed 
to  identify  it  later.)  We  consider  N  =  3  flows  taking  three  different  routes,  as  shown  in  Figure  2(a).  Notice  that  some  links 
are  shared  while  others  are  not.  For  example,  link  1  is  shared  between  flows  1  and  2,  but  link  3  only  carries  flow  2.  We  do 
not  show  link-capacity  values  here — these  values  are  specific  to  each  of  the  three  scenarios,  and  will  be  given  below. 

Time  is  divided  into  discrete  steps,  and  iterations  in  our  update  algorithms  coincide  with  these  steps.  Flow  rates  are 
interpreted  as  amounts  per  time  step,  just  like  in  any  discrete-time  fluid  model.  The  local  updating  agents  here  are  simply 
the  sources  of  the  flows  (i.e.,  each  of  the  three  flow  sources  update  their  own  flow  rates). 

The  sharing  of  links  is  handled  in  the  following  way.  At  (the  input  to)  each  link  we  maintain  one  queue  (buffer)  for 
each  flow  sharing  the  link.  Figure  2(b)  illustrates  the  three  queues  at  the  input  to  link  7.  At  each  time,  the  input  to  the 
queue  for  a  flow  at  a  link  is  equal  to  the  amount  of  flow  that  traversed  the  upstream  link  in  its  respective  route,  which  in 
turn  is  equal  to  the  output  of  the  queue  for  that  flow  at  that  upstream  link.  In  the  case  of  a  first  link  in  the  route  of  a  flow, 
where  there  is  no  upstream  link,  the  input  to  the  queue  is  the  flow  rate  generated  by  the  source  of  the  flow  at  that  time  step. 
The  queue  evolves  over  time  according  to  Lindley’s  equation: 

q(t  +  1)  =  [q(t)  +  (input  at  t)  —  (output  at  t)]  +  , 

where  q(t)  represents  the  amount  of  data  ( queue  length )  in  a  (generic)  queue  at  time  t.  Notice  that  at  any  given  time,  the 
input  to  the  queue  may  exceed  the  output — in  this  case,  the  excess  data  is  simply  queued,  contributing  to  an  increase  in  the 
queue  length. 

We  have  already  said  how  the  input  to  a  queue  at  time  t  is  calculated.  It  remains  to  describe  how  the  output  is 
determined.  The  basic  idea  is  that  the  link  capacity  is  divided  among  the  queues  at  that  link  (i.e.,  among  all  the  flows 
sharing  that  link).  Suppose  link  l  (with  capacity  ci)  has  three  queues,  with  queue  lengths  qi(t),  i  =  1,  2,  3.  We  divide  the 
capacity  c  in  proportion  to  the  queue  lengths: 
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output  of  queue  i  on  link  l  at  time  t  =  Ci 


This  method  of  calculating  the  link-capacity  share  for  each  flow  approximates  a  first-in-first-out  server  that  considers  all 
the  data  from  all  the  flows  together  in  a  single  queue.  Recall  that  the  link  rate  is  allowed  to  exceed  the  link  capacity — the 
excess  input  is  simply  buffered  in  the  queues,  according  to  the  sharing  mechanism  above. 

Because  of  the  queues  at  each  link,  the  data  that  is  transmitted  from  a  source  experiences  queueing  delays  along  the 
route  to  the  destination.  The  average  delay  at  a  queue  depends  on  the  ratio  of  the  rate  of  data  arriving  to  the  queue  (input 
rate)  to  the  server  capacity  of  the  queue  (output  rate) — this  ratio  is  called  the  load  factor.  The  load  factor  has  to  be  less 
than  one  for  the  queue  to  be  stable  (i.e.,  for  an  average  delay  to  exist).  In  our  rate  control  algorithm,  the  goal  is  for  each 
flow  rate  to  converge  to  an  optimal  rate,  which  may  be  such  that  the  link  rate  is  equal  to  the  link  capacity.  Therefore,  we 
can  control  the  asymptotic  load  by  setting  the  “target”  link  capacity  (what  we  called  c;  earlier)  to  be  a  fraction  of  the  actual 
link  capacity.  A  typical  value  of  this  fraction  in  a  practical  network  is  in  the  range  0.2-0. 7.  In  our  experiments  below, 
the  value  of  this  fraction  is  set  to  0.6,  which  leads  to  significant  queueing  delays.  This  serves  to  illustrate  the  impact  of 
delays  on  our  rate  control  algorithm.  Henceforth,  the  term  “link  capacity”  should  be  taken  to  mean  the  target  link  capacity 
(represented  by  ci),  which  is  a  fraction  of  0.6  of  the  actual  link  capacity. 

The  random  delays  in  the  propagation  of  flows  through  the  network  because  of  the  queues  at  each  link  are  not  the  only 
sources  of  delays.  In  our  experiments,  we  also  introduce  random  delays  to  the  transmission  of  prices  and  marginal  utility 
values  to  the  sources  (rate  updating  agents).  Specifically,  the  link  prices  used  during  each  rate  update  are  randomly  delayed 
versions  of  the  actual  link  prices.  Similarly,  the  marginal  utility  value  used  for  each  rate  update  is  the  marginal  utility 
evaluated  at  link  price  values  from  random  times  in  the  past.  In  our  experiments,  we  used  i.i.d.  geometrically  distributed 
delays  with  mean  10. 

In  our  experiments,  the  parameters  in  the  rate  control  algorithm  were  set  by  manual  tuning — this  turned  out  to  be 
relatively  easy.  More  systematic  methods  for  tuning  these  controller  parameters  are  available  in  the  literature  (e.g..  Ref.  6), 
but  a  discussion  of  these  methods  is  beyond  our  current  scope. 

In  all  scenarios  below,  the  minimum  flow  rates  m;  are  all  set  to  zero.  The  maximum  flow  rates  M,  are  taken  to  be 
sufficiently  large  not  to  matter  unless  otherwise  specified.  Similarly,  except  where  otherwise  specified,  the  link  capacity 
values  Ci  are  sufficiently  large  to  be  irrelevant.  In  the  scenarios  below,  we  set  specific  link-capacity  values  for  certain  links 
to  determine  which  links  are  “bottlenecks.” 

Scenario  1:  Independent  flows.  In  this  first  scenario,  we  consider  a  utility  function  of  the  following  form,  representing 
the  case  of  independent  flows: 

U(fl,f2,f3)=u(f1)  +  u(f2)  +  u(f3), 

where  u(f)  =  1  —  e~x.  The  network  link  capacities  are  as  follows:  C4  =  0.2,  C7  =  1,  and,  as  mentioned  before,  all  other 
ci  values  are  sufficiently  large  to  be  irrelevant.  In  other  words,  only  links  2  and  7  are  “bottleneck”  links — we  should  expect 
only  their  link  prices  to  be  nonzero,  and  all  the  others  zero.  The  only  constraining  maximum  flow  rate  parameter  here  is 
M2  =  0.3.  Some  reflection  on  this  simple  example  reveals  that  we  should  expect  the  optimal  flow  rates  to  be  as  follows: 
flow  2  should  be  limited  to  0.3  (because  of  M2),  flow  3  should  be  limited  to  0.2  (because  of  c2 ),  and  flow  1  to  take  up  the 
remaining  slack  of  link  7  (with  C7  =  1),  so  that  its  flow  is  0.5. 

Figure  3  shows  the  sequence  of  flow  rates  and  KKT  norms  plotted  as  a  function  of  time.  Notice  that  the  flow  rates  con¬ 
verge  to  the  values  we  expected  to  see,  based  on  our  discussion  above.  Indeed,  we  can  also  see  the  KKT  norm  converging 
to  zero,  providing  “certification”  of  convergence  of  the  flow  rates  to  optimality.  As  further  verification  of  this  optimality, 
we  solved  the  global  optimization  problem  offline  using  the  Matlab  tool  fmincon  (from  Matlab’s  optimization  toolbox). 
The  asymptotic  flow  rates  indeed  coincide  with  the  solution  obtained  using  fmincon  .  Moreover,  we  verified  that  the  link 
(and  route)  prices  also  converge  to  the  values  computed  using  fmincon  (because  of  space  limitations,  we  do  not  show 
plots  of  these  prices). 

Scenario  2:  Substitute  flows.  In  this  scenario,  we  consider  a  joint  utility  function  with  substitute  flows: 

U(f1J2,f3)=u(f1+f2  +  f3), 

with  u  as  in  the  Scenario  1.  Our  network  constraint  parameters  are:  c2  =  C4  =  cq  =  0.5.  An  inspection  of  the  network 
routes  suggests  that  flow  3  should  be  turned  off,  while  flows  1  and  2  occupy  the  entire  link  capacities  of  the  links  they  share 
with  flow  3  (links  2  and  6) — so  their  flow  rates  should  both  be  0.5. 


Figure  4.  Scenario  2:  Flow  rates  and  KKT  norm. 

Figure  4  shows  that  the  algorithm  behaves  as  expected,  converging  to  the  flow  rates  indicated  above,  and  with  KKT 
norm  converging  to  zero.  As  before,  our  fmincon  computation  yielded  the  same  result. 

Scenario  3:  Complementary  flows.  Finally,  we  consider  a  joint  utility  function  with  a  combination  of  independent 
and  complementary  flows: 

U {fa,  fa,  fa)  =  u{fi)  +  u{g{fa,fa)), 

where  g{fa,fa)  =  {{fa  +  e)-8  +  {fa  +  e)-8)-1/8  —  (2£-8)-1/8.  Some  explanation  is  in  order.  The  above  form  of 
utility  function  approximates  the  case  where  flows  2  and  3  are  perfect  complements:  g{f2,  fa)  «  min(/2,  fa).  The  perfect 
complementary  case  does  not  yield  to  a  differentiable  utility  function.  Two  modifications  are  necessary.  First,  we  use  the 
approximation  min(/2,  fa)  ~  {f2S  +  /if8)-1/8-  This  still  needs  modification  because  it  is  not  differentiable  at  0 — so  we 
add  £  to  fa  and  fa  and  shift  g  down  by  a  constant  so  that  g(0, 0)  =  0.  Here,  we  set  e  =  ICC3. 

We  set  the  link  capacities  as  follows:  ci  =  1  and  C4  =  0.4.  We  immediately  expect  =  0.4.  However,  because  of  the 
complementary  nature  of  flows  2  and  3,  we  also  expect  fa  w  0.4.  This  leaves  approximately  0.6  for  flow  1. 

Figure  5  shows  that  our  rate  control  algorithm  converges  to  the  flow  rates  we  expect  to  see,  and  that  the  KKT  norm 
converges  to  zero.  Once  again,  our  fmincon  computation  yielded  the  same  result. 

Realistic  tracking  scenarios.  Our  experiments  here  serve  primarily  to  illustrate  that  our  rate  control  method  converges 
to  optimality.  It  is  of  interest  to  perform  experiments  with  our  method  in  realistic  tracking  scenarios.  Specifically,  in  such 
scenarios,  the  utility  functions  are  derived  from  tracking  performance  metrics,  such  as  the  trace  of  the  error  covariance. 3 
Because  the  target(s)  being  tracked  and  the  sensor  platform  are  mobile,  the  utility  functions  are  also  typically  time  varying. 
In  this  case,  the  goal  is  not  convergence  to  optimal  rate  values  (which  applies  only  in  static  scenarios),  but  adaptivity  of 
rates  to  changing  conditions.  Because  of  space  limitations,  we  are  unable  to  provide  experimental  results  in  such  a  realistic 
setting.  These  will  be  available  in  a  forthcoming  paper. 


Figure  5.  Scenario  3:  Flow  rates  and  KKT  norm. 
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